Thanks for getting this started! I believe I need to change the timeout in GenLSP, as it's only waiting 5 seconds for you to click the button.

Also, that function should return with the response from the editor, so you'll need to use it. I assume that's why you say "they go nowhere"

Great work!

Ah, I hadn't dug deep and assumed the whole message cycle was going to be asynchronous. It seems like we need to handle the case where the user does nothing, ignores it, or doesn't get to the message in time. Can we tell the message to clear?

Also, I think I need to think a bit on the mix error capturing as well. There could be a legitimate error (like the dep won't compile because host tools are missing or something, etc) and we wouldn't want to prompt in that case. I think a majority of cases are solved with mix deps.get though

Ah, I hadn't dug deep and assumed the whole message cycle was going to be asynchronous. It seems like we need to handle the case where the user does nothing, ignores it, or doesn't get to the message in time.

I think that we most likely want the function to never time out, and if you want it to not block, you run it in a task and set a timeout on that, and handle accordingly.

Can we tell the message to clear?

i'll have to research that

Another thing to consider is the state of the runtime when we know there is an error with it.

Meaning, if there are errors, it should pause and wait for some direction and not just go into a restart loop

Another thing to consider is the state of the runtime when we know there is an error with it.

Meaning, if there are errors, it should pause and wait for some direction and not just go into a restart loop

🤔 hmm. This will take some thought as well. The mix deps.loadpath is what fails causing a non-zero exit of the private compiler port process which later gets handled and shuts things down. Is there currently a mechanism to leave the LSP and delay/retry the runtime start later?

It is probably acceptable to explicitly handle errors from the deps.loadpath call.

the runtime currently has some implicit state (if there is a node in the process state, it is considered "ready"), but it might be worth it to turn it into an explicit state machine (possibly using gen_statem)